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DETAILED ACTION 

1 . Claims 23-36 are pending. The Examiner acknowledges the cancellation of 
claims 1-22 and 37-40 and amended claims 23-26. 

Continued Examination Under 37 CFR 1.114 

2. A request for continued examination under 37 CFR 1.114, including the fee set 
forth in 37 CFR 1 .17(e), was filed in this application after final rejection. Since this 
application is eligible for continued examination under 37 CFR 1.114, and the fee set 
forth in 37 CFR 1 .17(e) has been timely paid, the finality of the previous Office action 
has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 23 July 
2008 has been entered. 

Response to Remarks/Argument 

3. Applicant's arguments with respect to claims 23-36 have been considered but are 
moot in view of the new ground(s) of rejection. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 1 03(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 
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5. Claims 23-36 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Taylor et al (U.S. Patent 6,654,830 B1 and known hereinafter as Taylor)(newly 
presented) in view of a Eastep (U.S. Patent 5,566, 328)(newly presented) and in further 
view of non-patent literature titled "A Scalable Content Distribution Service for Dynamic 
Web Content" by Seejo Sebastine, University of Virginia, 15 June 2001 (and known 
hereinafter as Sebastine)(previously presented). 

As per claim 23, Taylor teaches a method in a client-server computing network 
for reorganizing storage and accessing the reorganized storage (i.e. "A storage network that 
facilitates the transfer of a data set from a first storage device to a second storage device, without 
blocking access to the data set during the fransfer...")( Abstract), the method comprising: relocating 
a legacy share from a legacy server to a new server (Figure 1 illustrates relocating a legacy 

share (i.e. LUN A) from a legacy share (i.e. Device X) to a new server (i.e. Device Y).)(Figure 1 ); 
copying contents and permissions of the legacy share to the new server (i.e. "...the 
intermediate device maps all data access requests identifying the data set subject of the transfer and 
received on interface to link... "The Examiner interprets copying contents and permission as mapping all 
data access requests. )(coiumn 5, lines 60-62); aliasing the legacy share server name to resolve 
to the network address Of a consolidation server ("...Internet Protocol are used over the 
communication links carrying storage transactions on a variety of media in a variety of protocols. ")(column 

6, lines 38-60). 

Taylor does not explicitly teach creating a legacy server root associated with the 
name of the legacy server on the consolidation server; creating a link on the legacy 
server root corresponding to the legacy share on the new server; resolving the legacy 
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server name that is aliased to the consolidated server; receiving at the consolidation 
server request from a client for the legacy share path name. 

Eastep teaches creating a legacy server root (i.e. "for directories, the user can specify 

that a directory can be created or deleted .. ."){co\umn 1, lines 40-42) associated with the name Of 
the legacy server (i.e. "...rather than use the descriptive names of, e.g., "directory 1" or "filel", etc., 
more typical names are used such as would be encountered in a UNIX-like system." The Examiner 
interprets name of legacy server and consolidated server as typical names provided in a directory- 
enabled system. )(column 2, lines 17-20) on the consolidation server (i.e. "...operating system allows 
a user to create, access, and manipulate files and directories within a directory structure... ")(column 1, 

lines 35-39; see also Figure 1A); creating a link on the legacy server root corresponding to 
the legacy Share on the new server (Figures 1C and 1D established creating a link on a legacy 
server root (i.e. 7").)(Figures 1C, 1D); resolving the legacy server name that is aliased to the 

Consolidated Server (i.e. "The process of locating a file using a mathname is called pathname 
resolution. The product of pathname resolution is a file handle. A file handle is used by the operating 
system internally to refer to a file without having to resolve the file's name agfa/'n...")(column 2, lines 55- 
67; column 3, lines 1-5); receiving at the consolidation server request from a client for the 
legacy share path name (column 3, lines 35-40). 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicant's invention to modify the teachings of Taylor with the teachings of Eastep to 
include creating a legacy server root associated with the name of the legacy server on 
the consolidation server; creating a link on the legacy server root corresponding to the 
legacy share on the new server; resolving the legacy server name that is aliased to the 
consolidated server; receiving at the consolidation server request from a client for the 
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legacy share path name with the motivation to simplify management of storage 
systems, in particular the migration of data from one device to another (Taylor, column 
2, lines 5-7). 

The combination of Taylor and Eastep do not explicitly teach the consolidation 
server rewriting the legacy share path name by prepending the legacy share path with 
the consolidation server's own name; the consolidation server traversing the rewritten 
legacy share path name and resolving links within the rewritten legacy share path 
name; and the consolidation server responding to the client request with the share path 
name of the storage location of the relocated legacy share. 

Sebstine teaches a method comprising the consolidation server rewriting the 
legacy share path name by prepending the legacy share path with the consolidation 

server's own name (i.e. "By default, Squid rewrites any HTTP "Host:" headers in redirected requests 
to point to the new host to which the URL has been redirected, ")(Section 4.1.1; Appendex A); the 

consolidation server traversing the rewritten legacy share path name and resolving links 

within the rewritten legacy Share path name (i.e. "The URL rewriter module handles the job of 
rewriting the (redirected) URLs that the active server receives to fetch the script from the original content 
server. The address of the content server is specified in the HTTP "Host:" header as elucidated in section 
4.1.1. We have used the functionality provided by Apaches "mod re write" module to perform the URL 
rewriting. A sample rewrite-rule that can be used is given below: RewriteRule 7cgi-bin/(.*$) 
http://%{HTTP_HOST}/cgi-bin/$1 [P]. This rule states that all URLs which are meant to be served from the 
cgi-bin directory are to be rewritten to be served from the same directory, but on the host specified by the 
HTTP HOST environment variable. Since we wish to cache the script that is returned, we force this 
request to be a proxy request (indicated by [P]).")(Section 4.2.1); and the consolidation server 
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responding to the client request with the share path name of the storage location of the 

relocated legacy Share (i.e. "The URL rewriter module handles the job of rewriting the (redirected) 
URLs that the active server receives to fetch the script from the original content server. The address of 
the content server is specified in the HTTP "Host:" header as elucidated in section 4.1.1. We have used 
the functionality provided by Apaches "mod rewrite" module to perform the URL rewriting. A sample 
rewrite-rule that can be used is given below: RewriteRule 7cgi-bin/(.*$) http://%{HTTP_HOST}/cgi-bin/$1 
[P]. This rule states that all URLs which are meant to be served from the cgi-bin directory are to be 
rewritten to be served from the same directory, but on the host specified by the HTTP HOST environment 
variable. Since we wish to cache the script that is returned, we force this request to be a proxy request 
(indicated by [P]).")(Section 4.2.1). 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicant's invention to modify the teachings of Taylor with the teachings of Eastep and 
with the further teachings of Sebastine to include the consolidation server rewriting the 
legacy share path name by prepending the legacy share path with the consolidation 
server's own name; the consolidation server traversing the rewritten legacy share path 
name and resolving links within the rewritten legacy share path name; and the 
consolidation server responding to the client request with the share path name of the 
storage location of the relocated legacy share with the motivation to simplify 
management of storage systems, in particular the migration of data from one device to 
another (Taylor, column 2, lines 5-7). 

As per claim 24, Taylor teaches a method further comprising resolving an aliased 
legacy server name to establish a connection to the network address of a server (i.e. 
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"Input to the routine is a file id, the address of the specific host (hs_host) of the desired file and the rights 
desired for the file.")(Column 14, lines 36-38). 

As per claim 25, Taylor teaches a method further comprising sending an access 
request to the new server for the legacy share path name (i.e. "File specific server layer 208 is 

the layer that transforms SMBparser requests into cache and physical file system requests and also 
interfaces with the DFS token management service to manage the sharing of files between 
clients. ")(Column 4, lines 44-48). 

As per claim 26,Taylor teaches a method wherein the consolidation server and 
the new server are the same server (i.e. "DFS/DCE client software provides caches of files and 
directories to avoid network traffic. Additionally, they cache byte range locks, file opens and closes. To 
facilitate this, a token management scheme is used. If a client has a token with the needed rights for a file 
or directory, it can cache the data for that file or directory. It obtains these tokens from the central token 
manager (e.g., DFS token manager 214) residing at the file server.")(Column 5, lines 6-13). 

As per claim 27, Taylor and Eastep do not explicitly teach a method wherein 
rewriting the legacy share path comprises invoking a path rewriter to rewrite the legacy 
share path. 

Sebastine teaches a method wherein rewriting the legacy share path comprises 
invoking a path rewriter to rewrite the legacy share path (i.e. "By default, Squid rewrites any 
HTTP "Host:" headers in redirected requests to point to the new host to which the URL has been 
redirected, ")(Section 4.1.1; Appendex A). 
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It would have been obvious to a person of ordinary skill in the art at the time of 
Applicant's invention to modify the teachings of Taylor with the teachings of Sebastine 
to include a method wherein rewriting the legacy share path comprises invoking a path 
rewriter to rewrite the legacy share path with the motivation to simplify management of 
storage systems, in particular the migration of data from one device to another (Taylor, 
column 2, lines 5-7). 

As per claim 28, Taylor and Eastep do not explicitly teach a method further 
comprising encountering a link while traversing the rewritten legacy share path. 

Sebastine teaches a method further comprising encountering a link while 
traversing the rewritten legacy Share path (i.e. "Each script must be linked with this library in 
order to function correctly."" The Rewrite Rules Configuration File specifies a regular expression based 
pattern, which if matched results in the rest of the rule being executed. Just as in the Access Control List, 
the rules are matched in a linear order and hence the order of the rules is important. ")(Section 4.2.4; 
Appendex A.4). 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicant's invention to modify the teachings of Taylor with the teachings of Sebastine 
to include a method further comprising encountering a link while traversing the rewritten 
legacy share path with the motivation to simplify management of storage systems, in 
particular the migration of data from one device to another (Taylor, column 2, lines 5-7). 
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As per claim 29, Taylor and Eastep do not explicitly teach a method wherein 
resolving any links in the rewritten legacy share path comprises invoking a path 
redirector to resolve any links in the rewritten legacy share path. 

Sebastine teaches a method wherein resolving any links in the rewritten legacy 
share path comprises invoking a path redirector to resolve any links in the rewritten 
legacy Share path (i.e. "Each script must be linked with this library in order to function correctly." "The 
Rewrite Rules Configuration File specifies a regular expression based pattern, which if matched results in 
the rest of the rule being executed. Just as in the Access Control List, the rules are matched in a linear 
order and hence the order of the rules is important.")(Section 4.2.4; Appendex A. 4). 

It would have been obvious to a person of ordinary skill in the art at the time of 
Applicant's invention to modify the teachings of Taylor with the teachings of Sebastine 
to include a method wherein resolving any links in the rewritten legacy share path 
comprises invoking a path redirector to resolve any links in the rewritten legacy share 
path with the motivation to simplify management of storage systems, in particular the 
migration of data from one device to another (Taylor, column 2, lines 5-7). 

As per claim 30, Taylor teaches a method further comprising accessing the share 
path of the storage location of the relocated legacy share (i.e. "The method includes, for 

instance, accessing a file by a first client of the computing environment, the first client having a first 
protocol; and accessing the file by a second client of the computing environment, the second client having 
a second protocol. The second protocol is different from the first protocol, and wherein a change to the 
file by one of the first client and the second client is reflected to the other of the first client and the second 
client, thereby providing cache consistency.")(Column 2, lines 1-11). 
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As per claim 31 , Taylor teaches a method wherein accessing the share path of 
the storage location of the relocated legacy share comprises sending a Dfs create 
request to the network address of the storage location of the relocated legacy share (i.e. 

"DFS token manager 214 is the layer of the file server used to manage the tokens needed by the clients 
to access files. For example, DFS/DCE clients obtain tokens before performing an operation locally. That 
is, they use tokens to allow them to cache data, status and byte range locks without requiring a 
communication (e.g., a remote procedure call (RPC)) with the server; thus, reducing network traffic and 
increasing the access speed to remote files. A token represents a client's right to cache the data and it 
may represent its right to perform an operation.") (Column 4, lines 62-67). 

As per claim 32, Taylor teaches a method of claim 30 wherein accessing the 
share path of the storage location of the relocated legacy share comprises accessing a 

path of a separate Dfs namespace (i.e. "DFS token manager 214 is the layer of the file server 
used to manage the tokens needed by the clients to access files. For example, DFS/DCE clients obtain 
tokens before performing an operation locally. That is, they use tokens to allow them to cache data, 
status and byte range locks without requiring a communication (e.g., a remote procedure call (RPC)) with 
the server; thus, reducing network traffic and increasing the access speed to remote files. A token 
represents a client's right to cache the data and it may represent its right to perform an operation.") 
(Column 4, lines 62-67). 

As per claim 33, Taylor teaches a method further comprising encountering a Dfs 
reparse point while traversing the rewritten legacy share path (i.e. "dfs token manager 214 
is the layer of the file server used to manage the tokens needed by the clients to access files. For 
example, DFS/DCE clients obtain tokens before performing an operation locally. That is, they use tokens 
to allow them to cache data, status and byte range locks without requiring a communication (e.g., a 
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remote procedure call (RPC)) with the server; thus, reducing network traffic and increasing the access 
speed to remote files. A token represents a client's right to cache the data and it may represent its right to 
perform an operation.") (Column 4, lines 62-67). 

As per claim 34, Taylor teaches a method further comprising returning a 
message to the client indicating the path contains a link (i.e. "DFS token manager 214 is the 
layer of the file server used to manage the tokens needed by the clients to access files. For example, 
DFS/DCE clients obtain tokens before performing an operation locally. That is, they use tokens to allow 
them to cache data, status and byte range locks without requiring a communication (e.g., a remote 
procedure call (RPC)) with the server; thus, reducing network traffic and increasing the access speed to 
remote files. A token represents a client's right to cache the data and it may represent its right to perform 
an operation.") (Column 4, lines 62-67). 

As per claim 35, Taylor teaches a method further comprising receiving a referral 
request message from the client for the referral path (i.e. "DFS token manager 214 is the layer 
of the file server used to manage the tokens needed by the clients to access files. For example, 
DFS/DCE clients obtain tokens before performing an operation locally. That is, they use tokens to allow 
them to cache data, status and byte range locks without requiring a communication (e.g., a remote 
procedure call (RPC)) with the server; thus, reducing network traffic and increasing the access speed to 
remote files. A token represents a client's right to cache the data and it may represent its right to perform 
an operation.") (Column 4, lines 62-67). 

As per claim 36, Taylor teaches a computer readable medium having computer- 
executable instructions for performing the method of claim 23 (i.e. "The media has embodied 
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therein, for instance, computer readable program code means for providing and facilitating the capabilities 
of the present invention. ")(Column 19, lines 35-37). 
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